[MIRROR] Reactions correctly respect the REACTION_HEAT_ARBITARY flag
#1037
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…g [MDB IGNORE] (#25502) * Reactions correctly respect the `REACTION_HEAT_ARBITARY` flag (#80178) ## About The Pull Request 1. This flag basically adjusts the temperature of the whole holder without taking into consideration its heat capacity. If the reactions `thermic_constant` was negative this flag would not function correctly as it would clamp the rate of change between 0 and `CHEMICAL_MAX_TEMPERATURE` and then apply it to the final temperature. Now it clamps the final result(current temperature + rate of change) therefore reactions that uses this flag to cool down temps now works correctly. 2. Fixes #74667 The above point explains how the fix works. basically `thermic_constant` determines how much the holder temps cool down per unit of chem consumed. Cryostylane + oxygen reaction had this value at -50 which is way to low (cause it means per unit of oxygen consumed it would cool down the holder by 50 kelvin). It has been adjusted to -5 instead more reasonable. ## Changelog :cl: fix: Cryostylane and oxygen reaction now cools down temps. Other reactions with the `REACTION_HEAT_ARBITARY` flag also cools down temps correctly /:cl: * Reactions correctly respect the `REACTION_HEAT_ARBITARY` flag --------- Co-authored-by: SyncIt21 <[email protected]>
AnywayFarus
added a commit
that referenced
this pull request
Dec 9, 2023
Iajret
pushed a commit
that referenced
this pull request
Feb 18, 2024
* Makes the restricted number input user friendlier (#81495)
## About The Pull Request
The modal number input is extremely user unfriendly in it's current
state whenever used for negative and decimal numbers See #81457 for
details. The code might not be the best and if someone has suggestions
to optimize it, I'm all open for it, but it takes into aspect a lot of
edge cases to make the input as user friendly as possible. I've also
heard form some other code bases that they have issues with the
tgui_input_number proc.
The RestrictedNumber will get a new event to listen to though:
` onBlur={(_, value) => onBlur(value)}`
This will run the number through the previous, hard sanitation and
ensures that we always submit an allowed number and not a string value
as we are using it shortly during input for the pure `-` input.
(Especially important for the "Submit" button. Enter always handles it
that way). During testing, all the tested numbers were handled properly,
I could not see any issues on the inputs. We still keep some in Field
replacement, but it's for a limited range where we can have the field
handle numbers smart:
`min <= 1 && max >= 0`: Within that range, the field updates the value
to the restrains on input. In all other cases only onBlur.
Testcase table:
<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel"
xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta name=ProgId content=Excel.Sheet>
<!--table
{mso-displayed-decimal-separator:"\,";
mso-displayed-thousand-separator:"\.";}
@page
{margin:.79in .7in .79in .7in;
mso-header-margin:.3in;
mso-footer-margin:.3in;}
tr
{mso-height-source:auto;}
col
{mso-width-source:auto;}
br
{mso-data-placement:same-cell;}
td
{padding-top:1px;
padding-right:1px;
padding-left:1px;
mso-ignore:padding;
color:black;
font-size:11.0pt;
font-weight:400;
font-style:normal;
text-decoration:none;
font-family:Calibri, sans-serif;
mso-font-charset:0;
mso-number-format:General;
text-align:general;
vertical-align:bottom;
border:none;
mso-background-source:auto;
mso-pattern:auto;
mso-protection:locked visible;
white-space:nowrap;
mso-rotate:0;}
.xl63
{text-align:left;}
.xl64
{mso-number-format:"dd\/\\ mmm";
text-align:left;}
.xl65
{text-align:left;
vertical-align:top;}
.xl66
{mso-number-format:"\#\,\#\#0";
text-align:left;}
.xl67
{mso-number-format:"\@";
text-align:left;}
.xl68
{mso-number-format:"mmm\\ yy";
text-align:left;}
-->
</head>
<body link="#0563C1" vlink="#954F72">
Test case | Field Limit | Input | InField | OnEnter | OnSubmit | OnBlur
-- | -- | -- | -- | -- | -- | --
Float (smart) | 1-20 | 0 | 1 | 1 | 1 | 1
| | 1.1 | 1.1 | 1.1 | 1.1 | 1.1
| | 20.1 | 20 | 20 | 20 | 20
| | - | | 1 | 1 | 1
| | . | 1. | 1. | 1. | 1.
| | 5 | 5 | 5 | 5 | 5
Float | 2-20 | 0 | 0 | 2 | 2 | 2
| | 2.1 | 2.1 | 2.1 | 2.1 | 2.1
| | 5 | 5 | 5 | 5 | 5
| | 20.1 | 20.1 | 20 | 20 | 20
| | - | | 2 | 2 | 2
| | . | 2. | 2. | 2. | 2.
Float with decimal limit | 20.2-200.2 | 0 | 0 | 20.2 | 20.2 | 20.2
| | 20. | 20. | 20.2 | 20.2 | 20.2
| | 50 | 50 | 50 | 50 | 50
| | 200.3 | 200.3 | 200.2 | 200.2 | 200.2
| | - | | 20.2 | 20.2 | 20.2
| | . | 20. | 20.2 | 20.2 | 20.2
Float with decimal limit (smart) | 0-20.2 | 0 | 0 | 0 | 0 | 0
| | 20. | 20. | 20. | 20. | 20.
| | 5 | 5 | 5 | 5 | 5
| | 20.3 | 20.2 | 20.2 | 20.2 | 20.2
| | - | | 0 | 0 | 0
| | . | 0. | 0. | 0. | 0.
Negative Float (smart) | -10-20 | -10.2 | -10 | -10 | -10 | -10
| | 20. | 20. | 20. | 20. | 20.
| | 20.1 | 20 | 20 | 20 | 20
| | 0 | 0 | 0 | 0 | 0
| | - | - | -10 | -10 | -10
| | . | -10 | -10 | -10 | -10
| | -. | -10. | -10. | -10. | -10.
| | -10- | 10 | 10 | 10 | 10
| | 10- | -10 | -10 | -10 | -10
Negative Float with decimal limit | -10.2--20.2 | -10.1 | -10.1 | -10.2
| -10.2 | -10.2
| | -20. | -20. | -20. | -20. | -20.
| | -20.3 | -20.3 | -20.2 | -20.2 | -20.2
| | 0 | 0 | -10.2 | -10.2 | -10.2
| | - | - | -20.2 | -20.2 | -20.2
| | . | -20. | -20. | -20. | -20.
| | -. | -20. | -20. | -20. | -20.
| | -10.2- | 10.2 | -10.2 | -10.2 | -10.2
| | 10.2- | -10.2 | -10.2 | -10.2 | -10.2
Int (smart) | 1-20 | 0 | 1 | 1 | 1 | 1
| | 1. | 1 | 1 | 1 | 1
| | 21 | 20 | 20 | 20 | 20
| | 5 | 5 | 5 | 5 | 5
| | - | | 1 | 1 | 1
| | . | | 1 | 1 | 1
Int | 20-200 | 19 | 19 | 20 | 20 | 20
| | 201 | 201 | 200 | 200 | 200
| | 50 | 50 | 50 | 50 | 50
| | - | | 20 | 20 | 20
| | . | | 20 | 20 | 20
Negative Int (smart) | -10-20 | -11 | -10 | -10 | -10 | -10
| | 0 | 0 | 0 | 0 | 0
| | 21 | 20 | 20 | 20 | 20
| | - | - | -10 | -10 | -10
| | . | | -10 | -10 | -10
| | -. | - | -10 | -10 | -10
| | -10- | 10 | 10 | 10 | 10
| | 10- | -10 | -10 | -10 | -10
Negative Int | -200---20 | -201 | -201 | -200 | -200 | -200
| | -19 | -19 | -20 | -20 | -20
| | -50 | -50 | -50 | -50 | -50
| | - | - | -200 | -200 | -200
| | . | | -200 | -200 | -200
| | -. | - | -200 | -200 | -200
| | -20- | 20 | -20 | -20 | -20
| | 20- | -20 | -20 | -20 | -20
</body>
</html>
## Why It's Good For The Game
Even though not used often on TG code, the modal inputs are used on
other code bases and inputting numbers has been a hell if it was
anything other than a positive integer. This PR aims to make the
handling as user friendly as possible, even if it's a lot more edge case
checking than the very simple code beforehand.
## Changelog
fixes #81457
🆑
qol: makes the tgui_input_number user friendly for negative and decimal
inputs
code: the onBlur={(_, value) => onBlur(value)} event should now be used
on all uses of RestrictedInput to ensure that the number is fully
sanitized whenever the user leaves the field or submits it through a
button
/🆑
* Makes the restricted number input user friendlier
---------
Co-authored-by: Kashargul <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Mirrored on Skyrat: Skyrat-SS13/Skyrat-tg#25502
Original PR: tgstation/tgstation#80178
About The Pull Request
This flag basically adjusts the temperature of the whole holder without taking into consideration its heat capacity. If the reactions
thermic_constantwas negative this flag would not function correctly as it would clamp the rate of change between 0 andCHEMICAL_MAX_TEMPERATUREand then apply it to the final temperature.Now it clamps the final result(current temperature + rate of change) therefore reactions that uses this flag to cool down temps now works correctly.
Fixes #74667
The above point explains how the fix works. basically
thermic_constantdetermines how much the holder temps cool down per unit of chem consumed. Cryostylane + oxygen reaction had this value at -50 which is way to low (cause it means per unit of oxygen consumed it would cool down the holder by 50 kelvin). It has been adjusted to -5 instead more reasonable.Changelog
🆑 SyncIt21
fix: Cryostylane and oxygen reaction now cools down temps. Other reactions with the
REACTION_HEAT_ARBITARYflag also cools down temps correctly/:cl: